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(57) Abstract 



An Information Interface 
Provider (IIP) acting as the 
interface between a biller and its 
customers for both the presentment 
of electronic bills to the customers 
and for the processing of payments 
from the biller* s customers. The IIP 
creates and electronically publishes 
bills to the biller's customers in 
response to data provided by the 
biller and processes the payments 
in response to instructions provided 
by the customers. Bill publication 
is accomplished by any and/or all 
channels of distribution which are 
effective in reaching the customers 
of the biller including Internet web 
sites, Email and personal digital 
assistants, for example. Once 
billing data has been received by 
the IIP, the IIP formats the billing 
data for storage in its own internal 
database and then performs the 
task of reformatting the bill for the 
particular channel(s) of distribution 
selected by the customer. Several 




types of customer payments are 
processed by the IIP including 

Automated Clearing House (ACH) payments, credit or debit card payments, paper checks, smart card payments, and digital currency 
payments. Once the IIP has debited the consumer's account for the payment, it credits the account of the biller. The IIP consolidates all 
of the Accounts Receivable (A/R) information and presents the biller with a single file which can then be used by the biller to update its 
own internal A/R systems. 
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ELECTRONIC ACCOUNT PRESENTATION AND 
RESPONSE SYSTEM AND METHOD 

FIELD OF THE INVENTION 

- The present invention generally relates to 

systems and methods for publishing electronic 
information to consumers and for processing consumer's 
responses and more particularly to a system and method 
rcr presenting electronic bills to consumers and for 
1C processing consumer payments. 



BACKGROUND OF THE INVENTION 

Electronic Bill Presentment and Payment (EBPP) 
is an electronic alternative to the traditional paper 

15 bill presentation and payment methods which have 

dominated commerce since the establishment of postal 
services. Separate from the accounting costs, some of 
which will be incurred regardless of the method of bill 
presentment and payment, the cost of presenting and 

20 paying bills using traditional paper methods is 

astronomical. Large billers (credit card, mortgage, car 
loans, student loans...) are interested in EBPP for its 
cost displacement, revenue generation, and image 
enhancement potential . 

25 Using EBPP, an entity which generates invoices 

(bills) for its goods and services is able to present 
bills electronically to its customers and enables the 
consumer to pay the bills electronically. In one simple 
model of EBPP, the invoicing entity, hereinafter a 

30 "biller", generates the electronic bill itself and 



W <> 00/48102 

PC T/l/S00/02674 

- 2 - 

P re sents the ^ 

^ « in teia p e r t esentment is ^«;r its 

leve « 9 es the eS ' °»ect biller h <*> 9e nerate 
r «al ly h , °"lsr' S invest press! ntment 

; h ; d — t proc ;; ^ of blIaer 

15 ° f the can fce <CSP > ■ As stated « «• a Consumer 

P-esent me n t is \. ^ di ^dv antage Qf 
the r, that the. K--,, 9 ° f direr h w. 

c ^ process Q f ln hl ^er' s CUqt . Ct b ^le r 

! ° internet * lo<3 ^9 onto fch u CUStom ^ s must ini ,. 

ne t m order to , . he bi Her s c ^at iate 

This I- known in th ° ^ «vi«w and Da ^ °* 
te chnol 0gy ifl " the art a s an nd its biIls 

s tep of : f hlCh the con. Ple a "Pull- " 

P of ioggi burner must P 11 typ e 

thS -bove descr " ^ ^-'s s ite ^ 

;:r a ::^ 

fro,, cne direct h-n, Another.,,,,. 

, ° m a ™n sun ,e r . s „„. Presentment "^"wnt 

. eb sue;;:;;— - «vr a 

*° r ex ample ^ c a the 

x a c ustomer- s 



WO 00/481 02 PCT/US00/02674 



3 - 



telephone service provider maintains a direct bill 
presentment web site, the customer can only pay its 
telephone bill at that site, and not its cable bill. To 
pay the cable bill, the consumer must log off of the 
5 telephone company' s site and log onto the cable 

company's site. Still another disadvantage of direct 
bill presentment by the biller is that the biller must 
create a method by which the customer may pay the bill 
electronically while being logged onto the biller' s 

10 site. Although several methods of processing electronic 
payments have been developed over the last few years, it 
is up to the biller to adopt, maintain and/or outsource 
one or more of these methods. There are actually two 
functions associated with payment processing. First, 

15 the function of actually interfacing with the consumer 
is accomplished by an entity which is denoted as a 
Consumer Payment Provider (CPP) . The second function is 
processing the biller' s credits which is performed by a 
Biller Payment Provider (BPP) . Although these are two 

2 0 separate and distinct functions associated with payment 
processing, they are often performed by the same entity. 

A second model for EBPP is through a 
consolidated bill presentment site. Through this 
method, access to electronic bills from several billers 

25 is provided on a single bill presentment site. 

Typically a bank provides a bill presentment site, after 
it has agreement from several billers (or the agents of 
billers) to act as the electronic bill presenter on 
behalf of the billers. An advantage to the biller in 

30 using a consolidated site is that it avoids the costs of 
developing and maintaining the site itself. Although 
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the entity maintaining the consolidated site (the 
"consolidator" ) will charge the biller for the service 
(typically on a transactional basis) the costs to the 
biller are significantly less than a self maintained 
S site. Furthermore, the consolidator will typically 
provide some sort of payment processing service as 
described above. This is one reason which banks are 
drawn to this role, since banks typically have the 
systems and processes for payment processing. The 
consolidated approach is attractive to consumers in that 
a consumer can log onto a single site (typically with a 
single password) and have access to several electronic 
bills from several different billers. Another advantage 
of a consolidated site is that it does not exclude the 

li biller from separately maintaining its own direct 
presentation site as described above. Even if the 
tiller has its own Internet site which it uses for EBPP, 
the additional use of the consolidated site will only 
increase the likelihood that a biller' s customer will 

2 0 use EBPP and thereby save the biller money by avoiding 
the traditional, and costly, paper billing system. 

As with the direct bill presentment model 
described above, the greatest disadvantage of 
consolidated presentment is that it is a pull technology 

2 5 in which the consumers must initiate the process of 

logging onto the consolidated bill presentment site. 
Although it represents an advance over the direct 
presentation model, another disadvantage of the 
consolidated model is that a consumer can only 

3 0 electronically view and pay a subset of its bills at the 

consolidated site. The subset is usually defined by the 
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number of billers which a consolidator is able to 
attract to its site. The advantage of the Internet 
being accessible national -wide (international) is, in 
part, a disadvantage from the perspective of EBPP which 
5 must take into account regional or local bills. For 

example, two of the monthly bills typically paid by most 
consumers are telephone and utility bills. By their 
very nature, the billers for these services are 
organized on a regional or local basis. For this 

10 reason, consolidators have an easier time attracting 

national billers (e.g., Sears) than they have signing up 
a local utility company. Another disadvantage for a 
biller using a consolidator is that the biller loses a 
significant marketing opportunity with respect to its 

15 customers. Typically, a consolidator will only provide 
the biller with a limited capability to present 
marketing materials to its customers. Furthermore, 
there exists the potential that a competitor of biller 
will also appear on the consolidated site and 

2 0 potentially drain customers away from the biller. A 

final and significant disadvantage of consolidated bill 
presentment is that the biller must, in some form, 
provide its billing data to the consolidator. Separate 
from the technical details of formatting its billing 

25 data in a form which the consolidator can use, the 

biller loses control of the process by the employment of 
a consolidator. Although contractual and legal 
obligations can be created with respect to the 
consolidator, the biller must always be concerned that 

30 its customer's billing data provided to the third party 
consolidator is not mishandled or misused. 
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One additional model for EBPP is through the 
use of Email. In this model, the biller, or the 
biller's agent generates the electronic bill which is 
forwarded directly to the consumer's designated 
5 electronic mailbox (Email address) . The greatest 
advantage of this model is that, through the push 
technology of Email, the electronic bill is sent 
directly to the customer, without the customer having to 
take any action whatsoever. Naturally the customer must 
10 open his or her Email in order to actually view the 
electronic bill, but the consumer does not have to 
actively seek out the bill. Another advantage of the 
Email model is that, assuming all the customer's billers 
adopt this approach, all of the customer's bill arrive 
15 at a single mailbox. The Email model is closest 

parallel to the traditional paper billing process with 
which everyone is familiar. The most significant 
drawback of the Email model is the lack of security for 
the billing and payment information. Although 
20 encryption techniques are currently available, the lack 
of a consistent Email interfaces renders these 
encryption techniques difficult to practically 
implement. A further disadvantage of the Email model is_ 
the lack of a certification of delivery of the Email 
25 message containing the electronic bill. This generates 
uncertainty, both from the biller's and customer's point 
of view, whether or not a particular electronic bill was 
sent by the biller and/or received by the customer. A 
final drawback of the Email model is lack of any legal 
3 0 precedent governing this type of bill presentation. 
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In light of the disadvantages of each of the 
above described models for EBPP, there is a need felt in 
the industry for a system and method which: provides 
attractive financial opportunities for billers; 
5 maximizes consumer reach; guarantee privacy and 

security; facilitated rapid functional evolution; and 
avoids disruptions to a biller's systems and operations 
environment . 

10 SUMMARY OF THE INVENTION 

The present invention incorporates the 
advantages of each of the models described above in an 
integrated solution which minimizes the disadvantages 
associates with each model. The core of the present 

15 invention is an entity known as an Information Interface 
Provider (IIP) . The IIP takes on the role of the an 
information interface between a biller and its 
customers. In a preferred embodiment, the IIP provides 
a billing interface (for both bill presentment and 

20 payment processing) but the IIP is also able publish a 
variety of information for different types of entities, 
such as 401K statements for financial institutions. 
Although the below detailed description describes the 
preferred embodiment of electronic bill presentment, the 

25 present invention is not limited to such an embodiment. 
In its central function, the IIP creates and publishes 
bills to the biller's customers in response to data 
provided by the biller and processes the payments in 
response to instructions provided by the customers. The 

30 IIP maintains a Biller Acquisition Platform (BAP) which 
is a biller's single pipeline to the ever expanding EBPP 
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world. The BAP is not a presentment site, rather it is 
a staging area which facilitates presentment to the 
biller's customers via any vehicle (web sites, email...) 
and facilitates payment via any accepted payment 
5 mechanism (ACH, credit card, paper check, digital cash 
. . .) . 

The IIP accomplishes the bill publication by 
any and/or all channels of distribution which are 
effective in reaching the customers of the biller. 

10 These channels include, for example, traditional paper 
distribution, biller direct Internet site, a Customer 
Service Provider (CSP) operated Internet presentation 
site, consolidated Internet presentation sites, Email, 
personal digital assistants, voice response units, video 

15 phones, programmable cellular phones, interactive cable 
TV, interactive satellite TV, smartphones, telephones, 
facsimile, Automated Teller Machines (ATM), and pagers. 
In one embodiment of the present invention, the customer 
selects one channel by which it is to be presented bills 

2 0 and the IIP transmits the bill through that single 

channel of distribution. In an alternative embodiment, 
the customer can select several of the above channels 
and the IIP will ensure that the bill is available on 
each of the customer selected channels. In addition, 
25 the IIP can ensure that certain bills will only be 
published through certain channels. 

In providing the core billing function, the 
role of the IIP is to insulate its customers, the 
billers, from the physical task of presenting the bills 

3 0 to the consumers and from processing the payments from 

the consumers. In order to carry out the task of 
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presenting the bills to the consumer, the IIP must have 
access to the u raw" billing data from the biller. This 
access can be accomplished either through direct access 
by the IIP to the accounting systems of the biller or 
5 through a data feed from the biller to the IIP. Once 
the billing data has been received by the IIP, the IIP 
formats the billing data for storage in its own internal 
database and then performs the task of formatting the 
bill lor the particular channel (s) of distribution 

10 selected by the customer. Each biller has its own 

format and content for its "raw" billing data. Each 
channel of distribution has a distinct format and 
restrictions on content. Each customer has its own 
selected preference (s) for the channel on which the bill 

15 is to be presented. In light of all of these variables, 
the function of correctly formatting a particular bill 
for a particular customer is a significant task for the 
IIP. The present invention performs this formatting 
task using relational and object oriented databases 

2 0 which are the core of the BAP. 

In addition to presenting the bills, the IIP 
is also responsible for processing the payment from the 
consumers on behalf of the biller. As described above, 
an IIP performing this function is acting as a CPP . 

25 Several types of consumer payments are envisioned in the 
present invention including Automated Clearing House 
(ACH) payments, credit or debit card payments, paper 
checks, smart card payments, and digital currency 
payments. Furthermore, the IIP must be able to track 

30 preauthorized payments of certain bills by customers. 

Using preauthorization, the consumer may authorize the 
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IIP to debit a preselected consumer account with respect 
to certain bills, typically recurring bills for the same 
amount, e.g., a mortgage payment. Once the IIP has 
debited the consumer's account, it performs the role of 
5 a BPP and credits the account of the biller. The IIP 
consolidates all of the Accounts Receivable (A/R) 
information (i.e., which consumers have paid their bills 
and how much) and presents the biller with a single file 
which can then be used by the biller to update its own 

10 internal A/R systems. 

As described above, in addition to performing 
billing functions, the IIP has the capability to 
electronically publish virtually any type of information 
which an entity desires to distribute to its customers. 

15 For example, the IIP can provide electronic statements 
to the entity's customers Ce.g., a statement of a 401K 
account or an insurance policy) . Furthermore, the IIP 
can include marketing or other informational inserts in 
a presented statement or bill and perform ordering, 

2 0 payment and fulfillment functions with respect to the 
marketing and/or informational inserts. Additional 
functions of the IIP are to provide consolidated 
customer service data, collect and store customer 
enrollment data and customer preferences, and to provide 

25 a consolidated bill activation process. Each of these 

additional services performed by the IIP is ancillary to 
the core electronic publication function and can be 
performed or not performed at the request of the biller 
or other entity. In the preferred embodiment, since the 

30 goal of the IIP is to isolate the biller from the 

customer billing interface, it is anticipated that most 
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billers would want the IIP to perform these additional 
functions. Any statement or marketing inserts which are 
to presented to the customer must also go through a 
formatting process, depending on the intended channel of 
5 distribution. 

Customer service functions performed by the 
IIP include responding to customer and or biller 
inquiries regarding bills and payments. In one 
embodiment of the present invention, the role of the IIP 

10 is to either resolve the consumer's problem directly, if 
possible, or in any event to guide the consumer to the 
entity having responsibility for resolution of the 
problem (e.g., the consumer's bank, the biller itself, 
the CSP ...) . In an alternative embodiment, the IIP does 

15 not perform the customer service function directly, but 
rather maintains and provides the biller with access to 
a customer service database which can be utilized by the 
Customer Service Representative (CSR) of the biller in 
order to track customer service inquiries to their 

20 conclusion. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purposes of illustrating the present 
invention, there is shown in the drawings a form which 
25 is presently preferred, it being understood however, 
that the invention is not limited to the precise form 
shown by the drawing in which: 

Figure 1 is a schematic diagram illustrating 
the data flows between the Billers, the Information 
30 Interface Provider and the channels of distribution; 
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Figure 2 is an overview of the flow of data 
through the Biller Acquisition Platform; 

Figure 3 illustrates the flow of data during 
the enrollment process; 
5 Figure 4 is a flow chart illustrating the 

process of enrollment; 

Figure 5 illustrates the flow of data during 
the bill presentment process; 

Figure 6 is a flow chart illustrating the 
10 process of bill presentment; 

Figure 7 illustrates the flow of data during 
the payment process; 

Figure 8 is a flow chart illustrating the 
processing of payments through a CSP presentation site 
15 which has payment processing capabilities ; 

Figure 9 is a flow chart illustrating the 
processing of payments through a CSP presentation site 
which does not have payment processing capabilities; and 

Figure 10 is a flow chart illustrating the 
2 0 process of tracking and resolving customer service 
inquiries . 



DETAILED DESCRIPTION OF THE INVENTION 

As described above, although a preferred 
25 embodiment, the present invention is not limited to the 
electronic publication and processing of bills. As will 
be apparent to one skilled in the art, the present 
invention can electronically publish virtually any type 
of information which an entity desires to distribute to 
30 its customers. For example, the IIP can provide 

electronic account information relating to other goods 
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or service providers such as financial securities 
information (including 4 OIK data, proxy statements, 
prospectuses, checking or savings account statements, 
etc.), government related information (including tax 
5 reporting data, social security financial data, medicare 
data, etc.), medical information, insurance account 
information, and other business information (for 
example, airline ticketing, scheduling, shipment or 
purchasing information) . 

10 Figure 1 schematically illustrates the various 

entities and the flow of data according to the present 
invention. The Information Interface Provider (IIP) 2 0 
of the present invention is capable of providing billing 
services to any number of billers 5-15 through any 

15 number of channels of distribution 25-50 to the 

customers 80 of the billers. The only real limit on the 
number of billers that can be accommodated by the IIP 2 0 
are the physical facilities of the IIP 20 (e.g., phone 
lines, processors, data storage ...) . There is no 

20 restriction of the type of billers 5-15 that can use the 
IIP 20 of the present invention, other than the biller 
has accounting systems which can generate billing 
information on a recurring basis (or has accounting 
systems that can be accessed by the IIP 20) . For 

25 example, the IIP 20 can just as easily service a 

wholesaler (manufacturer) , a retailer (department store) 
or a service provider (telephone or utility service) . 
If the entity using the service of the IIP 20 is other 
than a biller, the only restriction is that the entity 

30 must be capable of providing (or providing access to) 
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the information which the entity wishes to be published 
to its customers 80 (e.g., 401K statement data). 

Four specific types of data 55-75 are depicted 
as flowing between a biller 5-15 and the IIP 20. 
5 Although only illustrated with respect to biller 5, the 
same types of data flows are applicable to all of the 
billers 5-15. In the embodiment depicted in Fig. 1, 
billing data 55 flows from biller 5 to IIP 20. In an 
alternative embodiment, the IIP 2 0 can access the legacy 

10 accounting files of the biller 5 directly in order to 

extract the required billing data 55. The format of the 
billing data 55 from biller 5 is determined by the 
biller 5. The IIP 20 places no restrictions on the 
format of the billing data 55 as it is received from 

15 biller 5, other than the IIP 20 has knowledge of the 
format of the data being delivered. As described in 
more detail below, it is the responsibility of the IIP 
20 to reformat the billing data 55 in the format 
required for its own internal databases and then to 

20 format the actual published bill, statement or other 
information as is appropriate for the channel of 
distribution particular to a specific customer 80 
receiving the presented bill or other information. 

In addition to the billing data 55, the biller 

25 5 may also provide marketing materials 60 that it 

desires to be presented to its customers 80. In one 
embodiment of the present invention , if the biller 5 
only desires certain customers 80 to receive certain 
marketing inserts 60, the biller 5 can identify which 

30 customers 80 are to receive which inserts 60. In an 

alternative embodiment, the IIP 2 0 provides value added 
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marketing in which, based on criteria provided by the 
biller 5, the IIP 2 0 can determine which customers 80 
are to be presented which marketing inserts. For 
example, if the biller 5 decides to run a rebate program 
5 in which, depending on the usage of the customer 

accounts, the biller 5 will provide discounts to the 
customer 80 on his next bill. In this example, the 
biller 5 could provide the criteria to the IIP 20 that 
if a customer's current bill is $100, the IIF 20 is to 

10 present an insert which offers the customer 80 a $10 

rebate on the next bill if it remains in excess of $100. 
The biller 5 could provide graduated rebates that 
increase with larger bills. With this criteria in hand, 
the IIP 20 is able to electronically query the current 

15 bills of all of the customers 80 of the biller 5, and 
insert the correct promotion into the bills which is 
presented to the customers 80. A further example of a 
marketing insert is a promotion being run by the biller 
5. For example if the biller 5 is credit card service 

2 0 provider, the biller 5 could be running a promotion for 
a new credit card which accumulates frequent flyer 
miles. An insert offer the new credit card can be 
presented to the customers 80 along with their credit 
card bill, or as completely separate presentment. 

2 5 Responses from the customers 8 0 to such inserts would be 
via link 70 depicted in Fig. 1. As described above, 
certain channels of distribution have restrictions on 
the format and content of such marketing inserts. For 
example certain Customer Service Providers (CSPs) with 

30 Internet presentment sites might limit such marketing 
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inserts to a certain size with no interactive 
capability. 

Element 65 in Fig. 1 represents the customer 
service link between the biller 5 and the IIP 20. This 
I link encompasses both electronic communication between 
biller 5 and IIP 2 0 as well as telephone and paper 
communications. The majority of data flowing in this 
link is related to the resolution of billing problems as 
nore fully described below. Additionally, customer 

1 : service data includes customer 80 address changes as 
well as status and preference changes related to 
customers 80. For example, a customer 80 might have 
been paying bills manually (i.e., reviewing the bill and 
initiating the payment of the bill after its review) . 

IE. At some point, the customer 8 0 might decide that he or 
she would like to have this bill paid automatically 
every month. This type of change information would 
typically be transmitted to the IIP 20 (typically from 
the customer 80 itself or from a CSP 35-40) which in 

20 turn would be transmitted to the biller 5 for its 
records . 

As will be more fully described below, the IIP 
2 0 forwards a consolidated payment file 70 to the biller 
5 reflecting the payments made by customers 80 during 

25 the applicable time period. In order to achieve one of 
its primary goals of insulating the biller 5 from the 
billing process, the IIP 20 consolidates all of the 
customer payments from all of the various channels of 
distribution 25-50 for which it is responsible, into a 

30 single Account Receivable (A/R) payment file. The 
single A/R payment file can then be used to update 
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biller's legacy A/R systems. This feature of the 
present invention alone is a significant advance over 
the prior art. In the prior art, the biller 5 was faced 
with accumulating different payment files from each of 
5 its channels of distribution and separately updating its 
in-house A/R files. Even if it was able to require each 
its agents managing the various channels of distribution 
to conform to a standard format and timing of the 
transmission of the payment files, the biller 5 still 

10 had to coordinate the updating of it's A/R files from 
several different payment files. In the present 
invention, the biller 5 receives a single payment file 
which reflects all of the payments received from its 
customers 80, regardless of the channel by which the 

15 customer 8 0 was presented the bill or the manner in 
which the customer 80 paid the bill. 

As described above, the IIP 2 0 also transmits 
customer responses 70 to the biller 5. In addition to 
the response described above with respect to a credit 

20 card service provider, responses 70 can also include any 
type of response or instruction from a customer 80 to 
the biller 5. For example, if the biller 5 is a 
financial services provider, the customer 80 can convey 
a buy a or sell instruction to the biller 5 via the IIP 

25 20. This type of customer instruction might be in 

response to a statement of the customer's 401K account 
which was electronically presented to the customer 80 
using the present invention. Such a 4 01K statement is 
illustrated in Fig. 1 under element 75 labeled "Other" . 

30 Element 75 is intended to illustrate any type of 

information which the biller 5 desires to transmit to 
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its customers 80. For example, an insurance company 
might want to present an update to a policy to a 
customer 8 0 using the present invention. Virtually any 
type of information which a biller 5 wishes to convey to 
5 its customers 80 can be safely and securely transmitted 
by the present invention which also enables secure 
communication back from the customer 80 to the biller 5. 

Five specific types of channels of 
distribution have been illustrated in Fig. 1: regular 

10 paper mail 25; Email 30; a biller direct presentation 

site 35, a Customer Service Provider (CSP) presentation 
site 40; and a consolidated CSP site 45. As previously 
described, the IIP 20 of the present invention is 
capable of taking u raw" billing data from a biller 5, 

15 and formatting the billing data in the appropriate way 

in order to present the bills to the customers 80 of the 
biller 5. As will be described below, the IIP 20 has 
knowledge of the channel (s) on which a particular 
customer 80 has selected for presentation of a bill and 

20 the IIP 20 formats the bill as appropriate for the 
selected channel . 

Channel 25 represents the traditional paper 
mail channel of distribution of bills. If a customer 80 
does not have access to an electronic channel (e.g., 

2 5 does not have a personal computer) or does not want to 
receive electronic bills, the IIP 20 receives the 
billing data from the biller 5 and generates a 
traditional paper bill for the customer 80. In one 
embodiment of the present invention, the IIP 20 itself 

30 generates the paper bills for publication to the 

customers 80. Alternatively, the IIP 20 outsources the 
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actual production and mailing of the paper bills to a 
third party. In addition in either of these 
embodiments, or in an embodiment in which the biller 5 
publishes the paper bills itself or outsources the 
5 publication, the IIP 20 can be responsible for all or 
part of the processing of payments from the customers 
80. For example, payments made in response to paper 
bills can be directed to the IIP 20 for processing and 
inclusion in the consolidated payment file 70 which is 

10 transmitted to the biller 5 by the IIP 20. 

Alternatively, the IIP 20 may only be delegated the 
responsibility for the processing of preauthorized, 
automatic payment of paper bills (whether or not the IIP 
2 0 even generated the paper bill) . The present 

15 invention has sufficient flexibility to accommodate any 
level of service requested'by the biller 5. 

Channel 3 0 represents an Email channel of 
distribution. If a customer 80 has selected to receive 
electronic bills via Email, upon receipt of the billing 

20 data from the biller 5, the IIP 20 formats the 

electronic bill, encrypts it and send the Email to the 
Email address previously provided by the customer 80. 
Once the Email message has arrived at the server 
containing the customer's Email account, the customer 8 0 

2 5 is able to open the message, decrypt and review the 

bill. In one embodiment of the present invention, the 
mechanism for effecting the customer's payment is 
included in the Email message, for example code which 
creates a "pay the bill" type button. In one example, 

30 this button may link the customer to a biller direct 

site 35 or another CSP site (e.g., one maintained by the 
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IIP 20) where the customer can pay the electronic bill. 
Alternatively, the Email message sent to the customer 
contains code which enables the customer to formulate 
its payment instructions which are then encrypted and 
5 sent back to the IIP 2 0 in a return Email message. In 
one further embodiment, the electronic bill sent to the 
customer via Email is directly analogous to a 
traditional paper bill and the customer 80 pays the bill 
through the more traditional channels (e.g., sending 
10 back a paper check) . 

Channel 3 5 represents an Internet web site 
maintained by or for the biller 5 directly. Most large 
commercial entities today maintain web sites for 
providing information to their customers 80 and for 
15 marketing their goods and or services. As part of these 
web sites 35, more and more corporations are providing 
the capability for customers 80 to review their accounts 
and review and pay electronic versions of their bills. 
Although some corporations maintain these web sites 
2 0 themselves, very often, the job of maintaining these 
sites is outsourced to other firms. Regardless of 
whether the site 35 is maintained in house or outsourced 
to another firm, the IIP 20 is capable of taking the 
"raw" billing data directly from the biller 5 and 
25 formatting the customer's bill electronically for 

presentation on the biller' s web site 35. As will be 
described below in detail, the IIP 20 is capable of 
processing instructions for payment received from 
customers 80 through the biller' s direct site 35. 
30 Two different CSP presentation sites 40 and 45 

are depicted in Fig. 1. CSP 4 0 represents a generic 



BNSDOCID: <WO 00481 02A2J_> 



WO 00/48102 



PCT/US00/02674 



- 21 - 



presentation site, while CSP 45 represents a 
consolidated site which is directly associated with a 
number of billers 5-15. Through the consolidated site 
45, a customer 8 0 can pay a number of bills from a 
5 variety of billers 5-15. Two examples of consolidated 
CSP sites 45 are Checkfree™ and Transpoint™ affiliated 
sites. Consolidated CSP Internet sites are typically 
developed and maintained by a third party entity. 
Typically, the third party entity enters a relationship 

10 with a biller or a financial institution (e.g., a bank) 
in which the site 45 is branded for the biller or the 
institution, but the interface and all of the 
functionality has been developed and is maintained by 
the third party such as Checkfree™ and Transpoint™. 

15 Although these two services will be used as examples 

throughout the remainder of this discussion, the present 
invention is in no way limited to functioning with 
solely these two CSPs . The IIP 20 of the present 
invention is capable of operating with any CSP 40 or 45, 

20 either now existing or arising in the future, which has 
defined interfaces and functionality. 

As with the biller' s direct site, the IIP 20 
formats the electronic bill in the format required by 
the particular CSP 40, 45, renders the electronic bill 

25 for the CSP 40, 45, which then presents the electronic 
bill to the customer 80. Some of the CSPs 40, 45 
existing today are capable of processing some forms of 
payments and not others. If the CSP 40, 4 5 is capable 
of processing the payment itself, it forwards the 

30 payment data to the IIP 2 0 for consolidation with the 
payment data from the remainder of the biller' s 
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customers 80. If the CSP 40, 45 is not capable of 
processing a payment, the customer's instruction for 
payment is transmitted to the IIP 2 0 which processes the 
payment and subsequently reports the payment to the 
5 biller 5 in the consolidated A/R file. 

Element 50 in Fig . 1 represents other channels 
of distribution already in existence and those yet to be 
developed . Other existing channels include telephone , 
personal digital assistants, pagers, video phones, Voice 

10 Response Units (VRU) , programmable cellular phones, 

interactive cable television, interactive satellite TV, 
smartphones, facsimile and Automated Teller Machines 
(ATM) for example. A telephone line can be used to 
review and pay bills through a Voice Response Unit (VRU) 

15 system. With a modem, the telephone can also be used to 
view and pay bills with a personal computer and 
appropriate software such as Quicken™ or MS Money™. In 
addition, element 5 0 represents other channels of 
payment back to the IIP 2 0 such as smart cards or 

2 0 digital currency . 

Fig . 2 illustrates an overview of structure of 
the elements of the present invention as well as the 
processing and data flow. Element 200 illustrates the 
structure of the Biller Acquisition Platform (BAP) . The 

25 central feature of the design of the BAP 200 is that it 
is a database driven system. The BAP 2 00 includes a 
database server 2 02 having , for example , six database 
including an Enrollment file 205; a Bill Summary file 
210 ; an E-Bill file 215 containing both current and 

30 historical data related to E-Bills; a Template file 200 
containing the templates required to format electronic 
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bills for the various channels of distribution 310-320; 
a Payment file 225 containing both currently pending 
payments and payments made over a certain period; an 
Inquiry file 230 for use in tracking and resolving 
5 customer and biller inquiries; and an Insert file 235 
containing marketing inserts. Each of the database 
files is structured on a biller by biller basis. The 
database files 205-230 can either be relational 
databases, object oriented databases or a combination of 

10 both types . 

The Enrollment database 205 contains all of 
the information relevant to the customers 8 0 of the 
biller 5. Examples of the type of information included 
in Enrollment database 2 05 includes, but is not limited 

15 to: customer name, biller account number, address, home 
phone, office phone, fax number, pager number, social 
security number, date of birth, maiden name, a 
'password' ; a preferred presentment vehicle (channel of 
distribution) and alternate presentment vehicles; 

20 customer presentment preferences (e.g., present my bill 
as soon as available, at the end of month, exception 
presentment (only present my bill if dollar amount 
exceeds a limit, otherwise automatically pay the bill, 
generate a paper bill if condition X occurs ...)); 

25 presentment configuration data (e.g., Email address, 
Email system/protocol, browser type and version . . .) ; 
bill format preferences (e.g., send me summary only, 
partial details, full details...); reminder preferences 
(e.g., as soon as possible, at end of month, 5 days 

3 0 before due date, on due date, 5 day late, no 

reminder. . . ) ; reminder channel (e.g. , email, paper 
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mail, fax, phone call, beeper. . .) ; preferred payment 
mechanism, a plurality of (e.g., nine) alternate payment 
mechanisms (i.e., IIP 20 needs to know all the payment 
options with respect to the client) ; payment 
5 preferences (e.g., preauthorized, on due date, at end of 
month, full or fixed amount, automatic within limit); 
and solicitation preferences (e.g., no solicitations, by 
industry (airlines, investments, ...); balance 
information (provided by a bank) , credit limits (defined 
10 by the issuer) and other limits (defined by the customer 
80) . 

The structure and content of the Summary file 
210 and the E-Bill file 215 varies from biller to 
biller. The Summary file includes the highest level 

15 representation of the customer's bill. Examples of the 
type of data included in the Summary file 210 are the 
customer's name, account number, location (address) of 
the bill destination, account balance, current amount 
due, amount past due, and minimum due. The E-Bill file 

20 215 contains data related to the customer's current E- 
Bills along with historical E-Bill data which is 
retained for a certain period of time. The E-Bill data 
residing in this file 215 contains the detailed 
description of the customer's bill (e.g., details of all 

25 of the charges on a credit card for the applicable 
period in the case of a credit card biller) . In a 
preferred embodiment of the present invention, the E- 
Bill file 215 is an object oriented file in which the E- 
Bills are stored as objects. The E-bill file 215 can be 

30 both industry specific and/or biller specific. For 

example, if the IIP 20 has several utility billers, a 
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standard format for a utility bill can be derived (e.g., 
a graph illustrating the customer's usage). Within the 
standard format, each utility biller can customize the 
format of its own bill to be presented to its customers 
5 80. Alternatively, each biller can custom format the 
entire look and feel of its bill. 

Insert file 235 contains the marketing inserts 
and/or other informational inserts described above. The 
data contained in the insert files is accessed at the 

10 time of the generation of the E-Bills which are to be 

presented to the customers 80. As described above, the 
biller can directly specify which customers 80 are to 
receive which inserts, or IIP 20 can provide a value 
added marketing service in which it identifies which 

15 customers 80 are to receive which inserts. 

The Payment file 22 5 contains the payments 
currently pending from the customers 80, payments being 
processed and a historical record of payments made by 
the customers 80. The Payment database 225 houses all 

20 data fields required to create an ACH or credit card 

payment as well as the fields needed to create payments 
via smart card, digital currency, and/or other future 
payment mechanisms. Additionally, the Payment file 225 
stores the data required to track the status of a 

25 payment (scheduled, in process, . . .) . In a preferred 
embodiment of the present invention, the Payment file 
225 is preloaded with all of the bills for the current 
period. As the bills are sent out and payments are 
made, the status of the bills in the Payment file 225 

30 will change. For example, if a customer 80 has 

preauthorized automatic payment of a bill, the bill 
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amount (and other bill related data) is preloaded in the 
Payment file 225 and the status of the bill is 
'scheduled'. At the time preauthorized by the customer 
80, the payment will be initiated and the status changes 
5 to 1 in process'. Once the payment has cleared, the 
status of the bill in Payment file 225 changes to 
'paid ' . 

The Inquiry file 230 is used to log and track 
the resolution of customer service inquiries from both 

10 customers 80 and billers 5. As described below, in a 

preferred embodiment of the present invention, the main 
use of this file is by the Customer Service 
Representatives designated by the biller 5, but can 
also be accessed by the billers 5 and customers 80 

15 directly. In a preferred embodiment, thirteen months of 
inquiries and responses are maintained in the Inquiry 
file 230. 

Element 24 0 is the application server for the 
BAP database system 200. The application server 240 
20 acts as the interface to the database server 202 which 
contains the database files 205-235. The application 
server 240 also acts as the interface of the BAP 200 to 
the external world (i.e., channels 310-320) through 
firewall 305. Although only a single firewall 305 has 
25 been depicted in Fig. 3, it will apparent to one skilled 
in the art that several firewalls and proxy servers can 
implement the external interface . 

Element 250 is the payment processing system 
for the BAP system 200. One example of a payment 
3 0 processor is the Customer Electronic Payment System™ 
(CEPS) developed by the Chase Manhattan Bank. The 
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function of the payment processing system 250 is to take 
payment instructions from a customer 8 0 and to execute 
these instruction in order to debit the payment from the 
customer's account and to credit the biller account. 
I- Two predominate ways in which the payment processing 

system 250 accomplishes this task is by interfacing with 
the Automated Clearing House network for debits from 
customer's Demand Deposit Accounts (DDA) (e.g., checking 
arrd savings accounts) and interfacing with Merchant 

1 Processors for charges against customer credit and debit 

c^rds (e.g., Visa™ or Mastercard™). In processing 
payments, the payment processing system 250 accesses 
Doth the Enrollment file 205 and the Payment File 225 in 
order to retrieve the customer's payment instructions. 

15 As the billing data from the biller' s legacy 

accounting systems is received by the BAP 200, it first 
goes through a splitter 255. The purpose of the 
splitter 255 is to separate the billing data with 
respect to customers 80 which are to be presented bills 

20 electronically by the IIP 20, and those which still 

desire to receive traditional paper bills. If a paper 
bill customer 80 has signed up for automatic payment 
processing, some of the billing data from biller 5 will 
be stored in the BAP 200. Otherwise, data related to 

25 customers 80 receiving paper bills is not retained by 
the IIP 20. One exception to this general rule is if 
the biller 5 desires to maintain electronic data for all 
of its customers 80, in anticipation of the customers 80 
eventually signing up for electronic bill presentment. 

30 In such a case, the IIP 20 is able to immediately 
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present an electronic bill to the previous paper 
customer 80 . 

If the biller 5 has contracted the IIP 20 to 
generate the paper bills, the billing data is routed the 
5 to system (e.g., an outsource not shown in Fig . 3 ) which 
generates and mails the paper bills. In an alternative 
embodiment, the biller 5 can have a different entity- 
generate and mail the paper bills, but have the IIP 20 
do all of the payment processing. In such a case, the 

10 IIP 20 retains, through splitter 255, at least a certain 
amount of the billing data. Furthermore, if IIP 20 is 
to maintain a complete customer service database, the 
IIP 20 may be contracted to retain all of the billing 
data related to paper customers 80 in order to 

15 facilitate use of the Inquiry database file 230. 

Element 245 is a reformatting processor which 
reformats the legacy billing data from the biller 5 in 
the appropriate format for inclusion on the database 
server 202. The billing data for the electronic bills 

20 is passed from the splitter 255 to the reformatting 

processor 245 once the splitter 255 has separated out 
the data for the paper bills. The details of the 
formatting by reformatting processor 245 varies from 
biller to biller and is driven by the format of the 

25 billing data provided by the biller. The reformatting 

processor 24 5 feeds the Summary data file 210 and the E- 
Bill database 215 with the data as described above with 
respect to each of these databases 210, 215. 

Fig. 3 additionally illustrates an overview of 

30 the processing and data flow in the BAP 200. The 

enrollment data regarding customers 80 can either be 
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manually entered and updated in Enrollment database 2 05 
and/or electronic files can be received, edited and 
uploaded into file 205. The enrollment data can either 
come directly to the BAP 200 (not shown in Fig. 3) from 
5 the customers 80 as illustrated in Fig. 3, or it can 
come from the biller 5, or one of the biller's CSPs 
(elements 40-45 in Fig. 1) . The BAP system 200 is 
capable of producing an audit trail of all additions, 
changes and deletions to and from Enrollment database 

10 205. Furthermore, with respect to Enrollment database 
205, BAP system 2 00 is capable of performing the 
following functions: extracting, reformatting, and 
transmitting the contents of the Enrollment data file 
205 to the billers 5; performing custom analysis of 

15 enrollment data and producing reports; generating ACH 

prenotes and processing negative responses; validating 
credit cards registered as a payment vehicle; 
receiving, storing, and retrieving image files of 
enrollment documentation; receiving and store balances 

20 and credit limits; generating customer correspondence 
(welcome, reminders...) based on the content of the 
Enrollment database 205 (via paper and email) ; 
triggering all types of automatic payments as scheduled 
in the enrollment preferences (in conjunction with 

2 5 payment processor 250) ; providing expandability for 
anticipated growth of enrollment data fields. 

As described above, billers 5 deliver legacy 
billing files to the BAP 200. The splitter 255 
identifies billing data associated with paper customers 

30 80 and handles the paper customer's billing data 
appropriately as described above. Reformatting 
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processor 245 executes mapping routines which reformats 
the variously formatted billing data from the billers 5 
into the format required for inclusion in the files 205- 
235 on database server 202. In addition to the 
5 transmission of billing data, a biller 5, or a biller's 
agent, at least once, delivers graphical templates and 
the indicators which link the different channels of 
distribution 310-320 to templates. Alternatively, the 
IIP 20 itself can develop a new template or modify an 

1. txisting template for the biller 5. The templates are 
stored in Template file 220 and are used during bill 
generation to format a bill for a particular customer 80 
that has identified a particular channel of 
distribution. For example, if the bill is to be 

15 presented on a biller's direct presentation Internet 

site 35 (Fig. 1), the Template file 220 will contain a 
template which will enable the billing data for that 
bill to be properly formatted for presentation on that 
site 35. As described above, the billers 5 also 

2 0 transmit to the BAP 2 00 any marketing inserts 6 0 

(advertising, regulatory, and/or informational Inserts) 
along with targeting logic which links customers 80 to 
inserts 60. This insert data is stored in Insert file 
235 . 

25 With respect to the Summary 210 and E-Bill 215 

data files, BAP system 200 is capable of performing the 
following functions : storing a predetermined amount 
(e.g., thirteen months) of bill data history for each 
biller 5; accepting manual entry/update of bill data and 

3 0 producing an audit trail; receiving, editing and 

uploading legacy billing data files from biller 5; 
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sending and receiving summary data; producing audit 
trails of all addition, change, and delete activity on 
files 210 and 215; extracting, reformatting, and 
transmitting billing data files; performing custom 
5 analysis of bill data and producing reports; and 

providing expandability for anticipated growth of bill 
and non-bill, data (e.g., marketing inserts 60) . With 
respect to the marketing inserts 60 contained in file 
235, the BAP 200 can: receive and store a predetermined 

10 amount (e.g., thirteen months) of insert history; 
receive, store and execute the logic required for 
developing and executing the conditional targeting 
associated with the marketing inserts 60; track a wide 
variety of access statistics (e.g., number read by 

15 customers 80, number responded to, types of customers 80 
who responded . . . ) ; online processing of responses from 
customers 80 (e.g., "I want to buy that luggage, please 
debit my account and send it to ..!"); and certification 
that an insert was read (for regulatory purposes among 

20 others) . 

Armed with all of the above, the BAP 200 is 
capable of creating an electronic bill. How the 
electronic bill is formulated (in an email, as an HTML 
page . . . ) and where it is delivered (to an email 

25 address, to a presentment site ...) will be governed by 
the customers' 80 enrollment data contained in database 
205. Application 'plug-ins' residing on application 
server 24 0 accomplish the actual formatting of the 
electronic bills. The plug-ins contain the software 

30 required to format the data in E-Bill 215 and Summary 
210 files for the channel of distribution to which an 
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electronic bill is to be published. There is a 
different plug-in for each channel of distribution. For 
example there is one plug- in for formatting the bill for 
a Voice Response unit channel of distribution and 
5 different plug-in for formatting a bill or an Internet 

web page. Furthermore, within a category of channels of 
distribution, there must specific plug-ins for each 
specific destination. For example, the formatting for 
one type of E-Mail browser is different than the format 

10 required for a different E-Mail browser. As additional 
channels of distribution are created and different 
devices for receiving information on those channels are 
developed, new plug- ins must be added to application 
server 240 in order to properly format electronic bills 

15 for those new channels and new devices. 

Once generated, the E-bill is transmitted to 
the customers 80 through the a firewall 305 and out 
distribution channels 310-320. The firewall 305 serves 
to protect the BAP 200 from unauthorized intrusion. As 

2 0 described above, the BAP 200 is capable of publishing 

bills to multiple presentment vehicles 310-320, either 
singly, simultaneously or sequentially. For example, 
one customer 80 might want its bills on a certain web 
page, while another customer 80 might ask to have its 
25 bills sent via E-Mail and posted on a web page 

simultaneously. The BAP 200 of the present invention 
easily accomplishes this function by merely formatting 
the same data from database server 202 for each of the 
channels requested by the customer 80 and sending them 

3 0 out the requested channels simultaneously. Similarly a 

customer 80 might request that its E-Bill is first 
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presented on an Internet site and if the bill is not 
paid within five days that the bill is sent to its E- 
Mail address. As described above, in addition to the 
electronic bills, the BAP 200 also presents documents 
5 and other non-bill information (such as statements and 

marketing inserts that may or may not be associated with 
bill payments) . 

In presenting E-Bills via Email, the BAP 200 
is capable of delivering secure Email notices of bill 

10 availability and providing a hot link to an appropriate 
web site, or the BAP can deliver secure bills directly 
via Email. The Email capability of the BAP 200 includes 
conforming to all standard Email Protocols (STMP, MIME, 
SMIME . . . ) . Without requiring software on the 

15 customer's Desktop, the BAP can certify that the Email 
was read, return secure payment instructions from the 
customer 80 via Email. The BAP 200 can also track 
unopened bills and generation reminders as specified in 
the reminder preferences contained in the Enrollment 

20 database file 205. 

If the E-bill is to be presented to a CSP or 
Biller direct site web page, the IIP 20 can send summary 
data to the CSP and dynamically render the required HTML 
pages. For Internet operations, the Server 24 0 and the 

25 firewall 305 allows customers 80 to view their E-Bills 
from any presentment site 310-320. As described above, 
the BAP 200 is capable of presenting bills to customers 
80 via virtually any channel 310-320 which can carry the 
bills such as Personal Financial Managers (PFM's, e.g., 

3 0 Quicken™ or MSMoney™ ) , video phones, interactive TV 
(cable or satellite), ATM ' s , pagers, VRUs , paper, 
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facsimile, or any other new presentment vehicle which is 
developed in the future. 

With respect to payments, the BAP 2 00 
initiates the automatic payments prescribed in the 
5 enrollment profiles 205 without any initiative required 
by the customers 80. As described above, the payment 
processor 250 accomplishes payment processing by 
executing customer payment instructions through external 
payment systems 32 5 such as ACH 33 0, Merchant Processors 

10 335 or other payment systems 340 (smart cards, digital 
cash ...) . For both management and customer service 
purposes, the BAP 2 00 keeps track of the status of 
customer payments, i.e., scheduled, in process, 
disputed, paid, and posted. As described above, some of 

15 the presentment vehicles, Transpoint™ for example, do 

not currently process payments. Instead they produce a 
file of payment instructions which is processed by the 
payment processor 250. These payments are also tracked 
as described above. The BAP 200 has the ability to 

2 0 extract, analyze, reformat, and transmit payment data. 
In addition to the above functions, the BAP 200 can: 
extract, reformat, and deliver payment data to 
destinations other than the payment processor 250 (e.g., _ 
back to the biller 5); receive, reformat, edit and 

2 5 upload payment data from other presentment vehicles 

(e.g., Transpoint™, biller direct sites, email...); 
receive, reformat, edit and upload posting data from 
billers 5; and analyze and proactively identify defined 
payment conditions such as "almost late" . 

3 0 The BAP 2 00 provides online access for 

customer service representatives (either from the IIP 



BNSDOCID: <WO 0O48102A2 I > 



WO 00/48102 



PCT/US00/02674 



- 35 - 



20, a biller 5, or a biller's other agent) in order to: 
view customer service inquiries; view a customer's bill; 
view and update enrollment data, view payment data; and 
create responses. The BAP 200 provides customer service 
5 representatives or other operators with the capability 
to: prioritize, assign and reassign open inquiries; 
proactively track response and the aging of responses; 
track the workflow tracking of the entire EBPP process 
(bill creation, reminders, insert responses, payments 

10 . . . ) ; create and store Management Information Services 
MIS data to support customer service inquiries; 
extract, reformat, and transmit customer service data to 
billers 5; spot check bills prior to publication; and 
provide full audit control over all add/change/delete 

15 activity. 

As described above, a predetermined amount 
(e.g., thirteen months) of customer service inquires and 
responses are maintained by the BAP 200. This 
information is used to provide different levels of 

20 support. For billers 5 that wish to provide their own 
customer service, the BAP 2 00 extracts, reformats and 
transmits the relevant data to the biller 5 
(alternatively, this information could be posted to a 
dedicated web site) . For billers 5 that wish to 

25 outsource the customer service function, the BAP 200 
provides online access to view, track, assign, and 
reassign the inquiries. 

Other capabilities provided by the BAP 200 
system include: an OLAP tool for analyzing data; a data 

30 mining tool (for identifying patterns) ; a data mapping 
tool; security of data stored in databases 205-235; 
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security of all data transmissions; security of all 
customer interfaces; the opportunity to use certificate 
authority; certified year 2000 compliant; an industry- 
wide biller/customer LDAP database; scalability for 
5 volume increase; disaster recovery; viability outside 
U.S. borders (128 bit encryption exportability , 
multilingual, multicurrency ...); and the ability to 
handle business to business EBPP. 

The process of enrollment will be discussed 

10 with respect to Figs. 3 and 4. Fig. 3 illustrates the 
flow of data during the enrollment process through the 
BAP 200 while Fig. 4 is a flow chart illustrating the 
process of enrollment. As illustrated in Fig. 4, the 
first step 400 in the enrollment process is the 

15 distribution of the solicitation materials. These 

materials can be distributed via any of the channels of 
distribution 310-320 (Fig. 3) previously described. For 
example the enrollment solicitation can be distributed 
via paper with the customer's existing traditional paper 

20 bill or can be posted on a CSP's presentment site. 

Steps 405-445 reflect the processing by three different 
Internet CSPs in responding to an enrollment request by 
a customer 80. Steps 405-415 relate to a CheckFree™ 
affiliated site, steps 420-430 relate to a TransPoint™ 

25 affiliated site, while steps 435-445 relate to other CSP 
Internet sites. 

With respect to CheckFree™ affiliated sites, 
in step 405 the customer 80 enrolls at the site and 
requests bill activation with respect to one or more 

30 billers 5. If the customer 80 is already enrolled with 
the CheckFree™ affiliated site, the customer 80 merely 
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requests bill activation with respect the billers 5 from 
which it desires E-Bills. What is meant by bill 
activation is that the customer 80 desires to be 
presented with electronic bills at the Checkfree™ 
5 affiliated site. Naturally, the customer 80 can only 
request bill activation with respect to billers 5 
affiliated with that site. If the customer 80 is 
enrolling at the Checkfree ™ affiliated site for the 
first time, in response to the enrollment request from 

10 the customer 80, CheckFree™, in step 410, generates a 
welcome letter and a prenote which verifies the 
existence of a customer's Demand Deposit Account DDA. 
In step 415, CheckFree™ sends the bill activation 
request to the IIP 20. 

15 The process of enrollment and bill activation 

at a TransPoint™ affiliated site is similar to that at a 
CheckFree™ affiliated site. In step 420 the customer 80 
enrolls and/or requests bill activation with respect to 
one or more billers 5. If the customer 80 is already 

20 enrolled with the Transpoint™ affiliated site, the 

customer 80 merely requests bill activation with respect 
the billers 5 from which it desires E-Bills. In 
response to the enrollment request, TransPoint™, in step 
425 generates a prenote and an activation code. The 

25 activation code is used as a security measure and is 

sent to the customer's mailing address (provided by the 
biller 5) in order to ensure that the entity enrolling 
is really the biller' s customer 80. In step 415, 
TransPoint™ sends the bill activation request to the IIP 

30 20. Steps 435-445 reflect the process of enrolling and 
activating the E-Bill presentation at a generic Internet 
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CSP and is similar to the process described above with 
respect the Checkfree™ and Transpoint™ affiliated sites 
The precise details of the enrollment process will 
differ from site to site. The result of the bill 
5 activation at any of the CSP sites is a request for 

activation which is sent to the IIP 20. The activation 
request must contain at least some subset of the data 
from the customer 80 outlined above with respect to the 
Enrollment database 205 (e.g., name, address, method of 

10 preferred payment . . . ) . 

In the embodiment of the present invention 
illustrated in step 450, bill activation requests are 
handled in the BAP 200 by the payment processor 250. 
Alternatively, a different processor in the BAP 200 can 

15 process bill activation requests. In step 455, the 
payment processor 250 consolidates and transmits the 
bill activation requests to the various billers 5 which 
are the targets of the requests. As depicted in Fig. 3 
the BAP 2 00 is also capable of directly receiving bill 

20 activation requests directly from customers 80 through 
letter, phone fax ... These directly received activation 
requests are consolidated with the CSP generated 
activation requests for transmission to the billers 5. 
In step 4 60 (Fig. 4) each biller 5 performs its own 

25 internal approval process with respect to the customers 
80 requests for bill activation and transmits its 
responses to the payment processor 250 in the BAP 200 
which updates the Enrollment database 4 65 with the 
biller 5 responses. In step 470, at the option of the 

30 biller 5, the IIP 20 sends the result of the approval 

process to the customer 80 via Email. In steps 475-485 
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the IIP 20 similarly sends the result of the biller' s 
approval process to the CSP which received the bill 
activation request from the customer 80. 

The process of bill presentment will be 
I discussed with respect to Figs. 5 and 6. Fig. 5 

illustrates the flow of data from a biller 5 through the 
IIP 20 and to customers 80 during the bill presentment 
process, and Fig. 6 is a flow chart illustrating the 
;. recess of bill presentment. Steps 600-610 in Fig. 6 

:: . liustrate the steps taken with respect to billing data 
:rom a biller 5, while steps 615-625 depict the 
analogous steps with respect to marketing inserts. In 
step 600, the biller 5 extracts the relevant billing 
data from its legacy A/R system and transmits this data 

15 :o the IIP 20. No special formatting of the billing 

data is required by the biller 5 as reformatting of the 
data is accomplished by the IIP 20 as described below. 
In step 605, upon receipt of the billing data from the 
biller 5, the IIP 20 splits out the data which is going 

20 co be sent to customers 80 via paper or electronically 
as described above. In step 610, the reformatting 
processor 245 (Fig. 5) reformats the billing data into 
the format required for insertion into the Summary and 
S-Bill Files 210, 215. 

25 With respect to inserts, in step 615 the 

biller 5 produces a hypertext markup language (HTML) 
version of the paper insert. In step 620 the biller 5 
transmits the HTML inserts and the targeting codes to 
the IIP 20 for inclusion in Insert database 235. The 

30 targeting codes enable the IIP 20 to be able to identify 
which customers 8 0 are to receive which inserts. In 
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step 625, the IIP 20, upon receipt of the insert files 
from the biller 5, loads the inserts into the Insert 
file 235 . 

After both the billing data and inserts have 
5 been received and properly formatted, the IIP 20, in 
step 630, loads the billing and insert data into a 
staging area from which this data is loaded into the 
databases 210-215 and 235. All of the data is now 
available and the bills and/or inserts can be presented 

10 to the customers 80. Steps 640-650 illustrate 

presentation of E-Bills to customers 80 at Checkfree™ 
affiliated sites, steps 655-665 illustrate presentation 
at Transpoint™ affiliated sites, and steps 670-680 
depict the flow of presentation at generic CSP Internet 

15 sites. In step 640 bill summary data is sent to and 
received by the Checkfree™ affiliated site. In step 
645, the bill summary is presented to the customer 80 
when he/she logs onto the site. In step 650, if 
desired, the customer 80 is able to view the detailed E- 

20 bill on the BAP 200 as is illustrated in Fig. 5. This 
is an optional step since the customer 8 0 can pay the 
bill without having to look at the detailed bill. 
Similar to the steps related to the Checkfree™ 
affiliated sites, the summary data is received by 

25 Transpoint™ or generic CSP sites (steps 655, 670) , the 
customer 80 is presented with summary data (steps 660, 
675), and the customer 80 is able to view the full, 
detailed E-Bill (steps 665-680) . 

After having the opportunity to review its 

30 bill, a customer 80 can initiate the payment process as 
is described in relation to Figs. 7-9. Fig. 7 
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illustrates the flow of data in the BAP 200 during the 
payment process, Fig. 8 is a flow chart illustrating the 
processing of payments through a CSP presentation site 
which has payment processing capabilities, while Fig. 9 
5 depicts the processing of payments through a CSP 

presentation site which does not have payment processing 
capabilities. Although the embodiments depicted in 
Figs. 8 and 9 have been illustrated with respect to a 
customer 80 paying though a DDA account, similar 

10 processes are followed with respect to the other payment 
mechanisms described above (e.g., credit cards, debit 
cards ...). In step 800, as illustrated in Fig. 8, a 
customer 80 clicks to pay its bill at a CSP presentation 
site which has payment processing capabilities (e.g., a 

15 Checkfree™ affiliated site) . The payment model depicted 
in Fig. 8 n steps 805-825 is known as a reversibility 
model since the credit to the biller 5 by the CSP can be 
reversed as a debit if the payment from the customer 8 0 
fails to clear. Other payment models known to those 

20 skilled in the art are a Risk-Based model, and a 

Guaranteed Funds model. The present invention can 
operate under either these three models (or any other 
suitable model) upon agreement with the biller 5. In 
step 805 of the Reversibility model, in response to the 

25 payment instruction by the customer 80, the CSP 

generates an ACH debit to the customer 80 to debit the 
account identified by the customer 80, and also credits 
the biller 5 in the amount debited from the customer 80. 
If the ACH instruction clears, the CSP generates an A/R 

30 file which is transmitted to the IIP 20 in step 810. 

The A/R file from the CSP is kept and consolidated with 
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other A/R files for ultimate transmission to the biller 
5. If the ACH does not clear (insufficient funds), the 
CSP, in step 815, automatically resubmits the ACH. If 
the ACH still does not clear the second time, the CSP, 
5 in step 820, debits the account of the biller 5, at 

which point it is the responsibility of the biller 5 to 
start a collection process against the customer 80 (step 
£25) . As an alternative to the CSP forwarding the A/R 
to the IIP 2 0 in step 810, the CSP can forward the A/R 

1C file directly to the biller 5. In such an embodiment, 
though, some of the "advantages of the present invention 
are lost in that the biller 5 will be receiving multiple 
A/R file from multiple locations (CSPs) instead of a 
single consolidated A/R file from the IIP 20. 

15 Fig. 9 illustrates the payment processing with 

respect to CSPs which do not have payment processing 
capabilities (e.g., most biller direct sites and a 
Transpoint™ affiliated sites). As illustrated in Fig. 9, 
when a customer 80 clicks to pay a bill from such a CSP 

20 presentation site (step 900) , the CSP transmits a 

payment instruction to the IIP 20 (step 905) . In step 
910, the IIP 20 updates the payment database 225 and 
send the payment instruction to the payment processor 
250. In step 915, the payment processor generates the 

25 ACH debits and credits from and to the customer 80 and 
biller 5 respectfully and transmits these instructions 
to the ACH network 33 0. In this embodiment, the 
customer 8 0 is paying its bill from a DDA account, thus 
the instruction to the ACH network. If the customer 8 0 

30 was paying by another means, e.g., a credit card, the 

payment processor would process the payment accordingly, 
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e.g., through the merchant processing system 335 (Fig. 
2). If the ACH instruction clears, the payment 
processor 250 updates the payment database 225 to 
reflect the payment (step 920) . In step 925, the IIP 20 
5 generates a consolidated A/R (reflecting the customer's 
payment along with all other payments for the applicable 
time period) which is transmitted to the biller 5. If 
the ACH does not clear (insufficient funds) , the payment 
processor 250 automatically resubmits the ACH in step 

10 930. If the ACH still does not clear a second time 

(step 935) the biller 5 starts its collection process 
against the customer 80 (step 940) . 

Fig. 10 is a flow chart illustrating the 
process of resolving customer service inquiries. In 

15 step 1000 a customer 80 inquiry is received by the 
Customer Service Representative (CSR) . The CSR can 
either be the biller 5, an entity outsourced by the 
biller 5, the IIP 20 or the CSP where the customer 80 is 
receiving its bills. In step 1005, the CSR creates a 

20 new record in the Inquiry database 230 (Fig. 2). This 
record will be used to track the customer's inquiry 
until its final resolution. In the preferred 
embodiment, the biller 5 will always be able to view and 
query the Inquiry database 23 0 in order to track 

25 customer's billing problems. In an alternative 

embodiment, the customers 80 themselves are able to view 
the Inquiry database with respect to the inquiries which 
have been initiated by them. In step 1010, the CSR 
determines the party with responsibility for resolving 

30 the customers 1 problem and directs the problem to that 
party. For example, if the bill was properly generated 
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by the IIP 2 0 and properly presented by the CSP, the 
problem is most likely with data supplied by the biller 
5. In such an example, the CSR informs the biller 5 of 
the problem, which then has responsibility for final 
5 resolution of the customer's problem. Once the CSR has 
identified the responsible party and directed the 
problem to that party, the CSR updates the Inquiry 
database 230 to reflect this determination. In steps 
1015 and 1020, the CSR monitors the resolution of the 

10 customer's problem and updates the Inquiry database 
accordingly . 

Although the present invention has been 
described in relation to particular embodiments thereof, 
many other variations and other uses will be apparent to 

15 those skilled in the art. It is preferred, therefore, 
that the present invention be limited not by the 
specific disclosure herein, but only by the gist and 
scope of the disclosure. 
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WHAT IS CLAIMED IS ; 

1. A system for presenting information from 
at least one provider to a plurality of customers over a 
plurality of electronic channels of distribution, the 

5 system comprising: 

a formatting processor for receiving the 
information from the provider and formatting the 
information for storage ,- 

a database server for (i) receiving and 
10 storing the information from the formatting processor, 
and (ii) storing customer data identifying at least a 
preferred one of the plurality of electronic channels of 
distribution; and 

an application server coupled to the database 
15 server and the plurality of electronic channels of 

distribution, the application server for (i) receiving 
the information from the database server, (ii) 
formatting the information for distribution over at 
least one of the electronic channels in response to at 
20 least some of the customer data, and (iii) distributing 
the information to at least one of the plurality of 
customers over the at least one preferred electronic 
channel of distribution. 

2. The system of claim 1, wherein the 
database server includes a customer database for storing 
the customer data including customer preference data 
identifying respective preferred electronic channels of 

5 distribution over which respective customers desire to 
receive the information. 



BNSDOCID: <WO 00481 02A2_I_> 



WO 00/48102 PCT/US00/02674 



46 - 



3. The system of claim 2, wherein the 
customer preference data identifies at least two 
preferred electronic channels of distribution for each 
customer . 

4. The system of claim 1, wherein the 
database server includes a template database for storing 
at least one template used by the application server in 
formatting the information for distribution over one or 

5 more of the plurality of electronic channels. 

5. The system of claim 1, wherein the 
database server includes an information database for 
storing the information formatted for storage by the 
formatting processor. 

6. The system of claim 1, further 

comprising: 

a splitting processor coupled to the 
reformatting processor, the splitting processor for 
5 identifying at least portions of the information related 
to customers that do not desire to receive the 
information electronically. 

7. The system of claim 6, wherein the 
splitting processor is operable to retain the identified 
information and pass the remaining information to the 
formatting processor. 
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8. The system of claim 1, wherein the 
information database includes at least summary 
information and detailed information. 

9. The system of claim 8, wherein the 
application server is operable to format the summary 
information and distribute the summary information to 
the customers . 

10. The system of claim 8, wherein the 
application server is operable to format the detailed 
information such that the at least one customer may view 
the detailed information. 

11. The system of claim 1, wherein the 
database server further comprises a marketing insert 
database for storing marketing information, the 
application server (i) formatting the marketing 

5 information for distribution over at least one of the 

electronic channels in response to at least some of the 
customer data, and (ii) distributing the formatted 
marketing information to the at least one customer along 
with the information. 

12. The system of claim 1, wherein the 
database server further comprises a response database 
for storing response information received by the 
application server from the at least one customer in 

5 response to the distributed information . 
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13. The system of claim 1, wherein the 
database server further comprises a customer service 
database for storing customer service information used 
for tracking customer problems, the customer service 

5 database being accessible by the at least one provider. 

14 . A method for presenting information from 
at least one provider to a plurality of customers over a 
plurality of electronic channels of distribution, the 
method comprising the steps of: 

5 receiving the information from the at least 

one provider ; 

formatting the information for storage; 
storing the information; 

storing customer data identifying at least a 
10 preferred one of the plurality of electronic channels of 
distribution over which respective customers desire to 
receive the information, 

formatting the information for distribution 
over at least one of the electronic channels in response 
15 to at least some of the customer data; and 

distributing the information to at least one 
of the plurality of customers over the at least one 
preferred electronic channel of distribution. 

15. The method of claim 14, wherein the 
customer data includes customer preference data. 

16. The method of claim 15, wherein the 
customer preference data identifies at least two 
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preferred electronic channels of distribution for each 
customer . 

17. The method of claim 14, for further 
comprising the step of storing at least one template for 
formatting the information for distribution over one or 
more of the plurality of electronic channels. 

18. The method of claim 14, further 
comprising the step of identifying at least portions of 
the information related to customers that do not desire 
to receive the information electronically. 

19. The method of claim 18, further 
comprising the step of discarding the identified 
portions of the received information. 

20. The method of claim 14, wherein the step 
of formatting the information for storage further 
comprises the step of generating at least summary 
information and detailed information. 

21. The method of claim 20, wherein the steps 
of formatting the information for distribution and 
distributing the information comprise the steps of 
formatting the summary information for distribution over 
at least one of the electronic channels and distributing 
the summary information to at least one of the 
customers . 
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22. The method of claim 20, further 
comprising the step of formatting the detailed 
information for distribution over at least one of the 
electronic channels such that the detailed information 
5 may be viewed by the customers. 



23. The method of claim 14, further 
comprising the steps of: 

storing marketing information; 

formatting the marketing information for 
5 distribution over at least one of the electronic 

channels in response to at least some of the customer 
data; and 

distributing the marketing information to the 
customers along with the information. 

24. The method of claim 14, further 
comprising the steps of : 

receiving response information from the at 
least one customer in response to the distributed 
5 information; and 

storing the response information. 

25. The method of claim 24, further 
comprising the step of transmitting the response 
information to the at least one provider. 

26. The method of claim 14, further 
comprising the steps of : 

storing customer service information used for 
tracking customer problems; and 
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S permitting the at least one provider access to 

the customer service information. 

27. A system for presenting billing 
information from at least one biller to a plurality of 
customers over a plurality of electronic channels of 
distribution, the system comprising: 

f a formatting processor for receiving the 

Lilling information from the at least one biller and 
r^rmatting the billing information for storage; 

a database server for (i) receiving and 
storing the information from the formatting processor, 

I :< and (ii) storing customer data identifying at least a 

preferred one of the plurality of electronic channels of 
dis t r ibut ion ; and 

an application server coupled to the database 
server and the plurality of electronic channels of 

15 distribution, the application server for (i) receiving 
the billing information from the database server, (ii) 
formatting the billing information for distribution over 
at least one of the electronic channels in response to 
a: least some of the customer data, and (iii) 

20 distributing the billing information to at least one of 
the plurality of customers over the at least one 
preferred electronic channel of distribution. 

28. The system of claim 27, wherein the 
database server includes an enrollment database for 
storing the customer data including customer preference 
data identifying respective preferred electronic 
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5 channels of distribution over which respective customers 
desire to receive the billing information. 

29. The system of claim 28, wherein the 
customer preference data identifies at least two 
preferred electronic channels of distribution for each 
customer . 

30. The system of claim 27, wherein the 
database server includes a template database for storing 
at least one template used by the application server for 
formatting the billing information for distribution over 

5 one or more of the plurality of electronic channels. 

31. The system of claim 27, wherein the 
database server includes an electronic bill database for 
storing the billing information formatted for storage by 
the formatting processor. 

32. The system of claim 27, further 
comprising : 

a splitting processor coupled to the 
formatting processor, the splitting processor for 
5 identifying at least portions of the billing information 
related to customers that do not desire to receive the 
information electronically . 

33. The system of claim 32, wherein the 
splitting processor is operable to retain the identified 
billing information and pass the remaining billing 
information to the formatting processor. 
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34. The system of claim 27, wherein the 
information database includes at least summary billing 
information and detailed billing information. 

35. The system of claim 34, wherein the 
application server is operable to format the summary 
billing information and distribute the summary billing 
information to the customers. 

36. The system of claim 34, wherein the 
application server is operable to format the detailed 
billing information such that the customers may view the 
detailed billing information. 

37. The system of claim 27, wherein the 
database server further comprises a marketing insert 
database for storing marketing information, the 
application server (i) formatting the marketing 

5 information for distribution over at least one of the 

electronic channels in response to at least some of the 
customer data, and (ii) distributing the formatted 
marketing information to the at least one customer along 
with the billing information. 

38. The system of claim 37, wherein the 
database server further comprises a response database 
for storing response information received by the 
application server from the at lest one customer in 

5 response to the distributed billing information. 
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39. The system of claim 27, wherein the 
database server further comprises a customer service 
database for storing customer service information used 
for tracking customer problems, the customer service 

b database being accessible by the at least one biller. 

40. The system of claim 27, further 
comprising a payment processor for receiving payment 
instructions from the at least one customer in response 
to the distributed billing information, the payment 

i processor executing the received payment instructions . 

41. The system of claim 40, wherein the 
database server further comprises a response database 
for storing the received payment information and storing 
payment status information reflecting the status of the 

S execution of the received payment instructions by the 
payment processor . 

42. The system of claim 40, wherein the 
payment processor is coupled to an external Automated 
Clearing House (ACH) network, wherein certain of the 

10 received payment instructions are requests to debit 

customer's Demand Deposit Accounts (DDA) , and wherein 
the payment processor is operable to execute the certain 
received payment instructions by transmitting debit 
instructions to the ACH network. 

43. The system of claim 42, wherein the 
payment processor is operable to transmit credit 
instructions to the ACH network with respect to an 
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account of the at least one biller in response to the 
5 transmitted debit instructions. 

44. The system of claim 40, wherein the 
payment processor is coupled to an external Merchant 
Processing network, wherein a plurality of the received 
payment instructions are requests to debit customers 1 

5 credit or debit card accounts, and wherein the payment 
processor is operable to execute the plurality of 
received payment instructions by transmitting debit 
instructions to the Merchant Processing network. 

45. The system of claim 44, wherein the 
payment processor is operable to transmit credit 
instructions with respect to an account of the at least 
one biller in response to the transmitted debit 

5 instructions. 

46. The system of claim 40, wherein the 
enrollment database is operable to store automatic 
payment instructions specified by the customers and the 
payment processor- is operable to execute the automatic 

5 payment instructions. 

47. The system of claim 46, wherein the 
automatic payment instructions specify a time at which 
the automatic payment instruction is to be executed and 
wherein the payment processor is operable to execute the 

5 automatic payment instructions at the specified time. 
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48. The system of claim 40, wherein the 
enrollment database is operable to store customer 
payment account information identifying at least one 
account of each customer against which payments by the 

5 customers are to be debited. 

49. The system of claim 48, wherein the 
payment processor is operable to execute the received 
payment instructions in response to the customer payment 
account information stored in the enrollment database. 

50. The system of claim 40, wherein the 
payment processor is operable to generate a consolidated 
account receivable file reflecting all payments executed 
by the payment processor during a predetermined period 

5 of time. 

51. The system of claim 50, wherein the 
payment processor is operable to transmit the 
consolidated account receivable file to the at least one 
biller . 

52. The system of claim 27, wherein the 
plurality of electronic channels of distribution are 
selected from the group consisting of Internet web site, 
Email, personal digital assistant, voice response unit, 

5 video phone, programmable cellular phone, interactive 
cable TV, interactive satellite TV, smartphone, 
telephone, facsimile, Automated Teller Machine (ATM), 
and pagers . 
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53. The system of claim 27, wherein the 
system is operable to present billing information with 
respect to a plurality of billers, the system further 
comprising a plurality of database servers, each 

5 database server corresponding to one of each of the 
billers, each of the plurality of database servers 
comprising databases related to the customers of the 
biller corresponding to the database server. 

54. A method for presenting billing 

10 information from at least one biller to a plurality of 
customers over a plurality of electronic channels of 
distribut ion, the method comprising: 

receiving the billing information from the at 
least one biller; 
15 formatting the billing information for 

storage; storing the billing information; 

storing customer data identifying at least a 
preferred one of the plurality of electronic channels of 
distribution over which respective customers desire to 
20 receive the billing information; 

formatting the billing information for 
distribution over at lest one of the electronic channels 
in response to at least some of the customer data; and 
distributing the billing information to at 
25 least one of the plurality of customers over the at 

least one preferred electronic channel of distribution. 

55. The method of claim 54, wherein the 
customer data includes customer preference data. 
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56. The method of claim 55, wherein the 
customer preference data identifies at least two 
preferred electronic channels of distribution for each 
customer . 

57. The method of claim 55, further 
comprising the step of storing at least one template for 
formatting the billing information for distribution over 
one or more of the plurality of electronic channels. 

58. The method of claim 54, further 
comprising the step of identifying at least portions of 
the billing information related to customers that do not 
desire to receive the information electronically. 

59. The method of claim 58, further 
comprising the steps of: 

retaining the identified billing information; 

and 

passing on the remaining billing information 
for formatting and storage. 

60. The method of claim 54, wherein the step_ 
of formatting the information for storage comprises the 
steps of generating at least summary billing information 
and generating detailed billing information. 

61. The method of claim 60, further 
comprising the steps of formatting the summary billing 
information for distribution and distributing the 
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summary billing information to at least one of the 
5 customers . 



62. The method of claim 60, the steps of 
formatting the detailed billing information for 
distribution over at least one of the electronic 
channels and permitting at least one of the customers to 
5 view the detailed billing information. 



63 . The method of claim 54 , further 
comprising the steps of : 

storing marketing information; 

formatting the marketing information for 
5 distribution over at least one of the electronic 

channels in response to at least some of the customer 
data; and 

distributing the marketing information to the 
at least one customer along with the billing 
information. 



64 . The method of claim 54 , further 
comprising the steps of : 

receiving response information from the at 
least one customer in response to the distributed 
5 billing information; and 

storing the response information. 

65. The method of claim 54, further 
comprising the steps of: 

storing customer service information used for 
tracking customer problems; and 
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5 providing access to the stored customer 

service to the at least one biller. 

66. The method of claim 54, further 
comprising the steps of: 

receiving payment instructions from at least 
one customer in response to the distributed billing 
5 information; and 

executing the received payment instructions. 

67. The method of claim 66, further 
comprising the steps of: 

storing the received payment information; and 
storing payment status information reflecting 
5 the status of the execution of the received payment 
instructions . 

68. The method of claim 66, wherein certain 
of the received payment instructions are requests to 
debit customer's Demand Deposit Accounts (DDA) , the step 
of executing the received payment instructions 

5 comprising transmitting debit instructions with respect 
to the certain received payment instructions to an 
external Automated Clearing House (ACH) network. 

69. The method of claim 68, further 
comprising the step of transmitting credit instructions 
to the ACH network with respect to an account of the at 
least one biller in response to the transmitted debit 

5 instructions. 
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70. The method of claim 66, wherein a 
plurality of the received payment instructions are 
requests to debit customer's credit or debit card 
accounts, the step of executing the received payment 

5 instructions comprising transmitting debit instructions 
with respect to the plurality of received payment 
instructions to an external Merchant Processing network. 

71. The method of claim 70, further 
comprising the step of transmitting credit instructions 
with respect to an account of the at least one biller in 
response to the transmitted debit instructions. 



72. The method of claim 54, further 
comprising the steps of: 

storing automatic payment instructions 
specified by at least one of the customers; and 
5 executing the automatic payment instructions. 



73. The method of claim 72, wherein the 
automatic payment instructions specify a time at which 
the automatic payment instruction is to be executed, the 
method further comprising the step of executing the 

5 automatic payment instructions at the specified time. 

74. The method of claim 54, further 
comprising the step of storing customer payment account 
information identifying at least one account of each 
customer against which payments by the customers are to 

5 be debited. 
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75. The method of claim 74, wherein the step 
of executing the received payment instructions is in 
response to the customer payment account information 
stored in the enrollment database. 

76. The method of claim 54, further 
comprising the step of generating a consolidated account 
receivable file reflecting all payments executed during 
a predetermined period of time. 

77. The method of claim 76, further 
comprising the step of transmitting the consolidated 
account receivable file to the at least one biller. 

78. The method of claim 54, wherein billing 
information is presented to customers of a plurality of 
billers, the method further comprising the step of 
maintaining a plurality of databases, each database 

5 corresponding to one of each of the billers and 

containing data related to the customers of the biller 
corresponding to the database. 

79. An information distribution system for 
distributing information from an information provider to 
a plurality of consumers, said system comprising: 

interfaces to a plurality of electronic 
5 channels of distribution; 

a database containing : 

consumer information indicating, for each 
of said consumers, a preferred one of 
said electronic channels on which said 



BNSDOCID: <WO 00481 02A2J_> 



WO 00/48102 



PCT/US00/02674 



- 63 - 



10 information is to be sent to said 

consumer, and 

at least one template for each of said 
electronic channels, each of said 
templates indicating a format of said 
I > information to be sent over a 

corresponding electronic channel; and 
a processor receiving said information for a 
given consumer from said information provider and 
transmitting said received information to said consumer 
over said preferred- electronic channel in a format 
determined by one of said templates corresponding to 
said preferred channel. 

80 . The information distribution system as 
recited in claim 79 wherein one of said electronic 
channels of distribution is capable of conveying 
electronic mail and wherein said processor transmits 

£ said information in an electronic mail message. 

81. The information distribution system as 
recited in claim 80 wherein said electronic mail message 
contains a response mechanism enabling said consumer to 
respond to said information. 

82 . The information distribution system as 
recited in claim 81 wherein said response mechanism 
links said consumer to an Internet facility maintained 
by said information provider. 
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83. The information distribution system as 
recited in claim 81 wherein said response mechanism 
links said consumer to an Internet facility coupled to 
said information distribution system. 

84. The information distribution system as 
recited in claim 79 wherein said consumer information 
further includes a time at which said information is to 
be transmitted to said consumer . 

85. The information distribution system as 
recited in claim 84 wherein said time at which said 
information is to be transmitted is as soon as said 
information is received from said information provider. 

86. The information distribution system as 
recited in claim 84 wherein said time at which said 
information is to be transmitted is at the end of a 
month . 

87. The information distribution system as 
recited in claim 79 wherein said consumer information 
further includes at least one rule governing said 
transmission of said information . 

88. The information distribution system as 
recited in claim 87 wherein said at least one rule 
indicates that said information should be transmitted 
only if it relates to a transaction above a dollar 

5 amount threshold. 
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89. The information distribution system as 
recited in claim 87 wherein said at least one rule is 
defined by said consumer. 

90. The information distribution system as 
recited in claim 79 wherein said consumer information 
further includes alternative electronic channels on 
which said information can be sent to said consumer. 

91. The information distribution system as 
recited in claim 90 wherein said processor transmits 
said information on one of said alternative electronic 
channels if said consumer has not responded to said 
information transmitted on said preferred electronic 
channel . 



92. The information distribution system as 
recited in claim 79 wherein said processor transmits a 
reminder to said consumer if said consumer has not 
responded to said transmitted information. 



93 . The information distribution system as 
recited in claim 92 wherein said consumer information 
includes at least one rule defined by said consumer 
governing said transmission of said reminder. 



94. The information distribution system as 
recited in claim 93 wherein said at least one rule 
defines a time at which said reminder is to be 
transmitted . 



BNSDOCI D: <WO 0048 1 02A2_I_> 



WO 00/48102 



PCT7US00/02674 



- 66 - 



95. The information distribution system as 
recited in claim 79 wherein said database further 
contains historical information related to said 
information received from said information provider. 

96. The information distribution system as 
recited in claim 95 wherein said database further 
contains audit information with respect to additions, 
changes and deletions of said historical information. 

97. The information distribution system as 
recited in claim 79 wherein said processor receives 
information respectively designated for said plurality 
of consumers and transmits said information to said 

E respective consumers over each of said respective 
consumer ' s preferred electronic channel . 

98. The information distribution system as 
recited in claim 79 wherein said processor receives 
insert information and conditions from said information 
provider, said processor identifies a subset of said 

5 plurality of consumers in response to said conditions 

and transmits said insert information to said subset of 
consumers . 

99. A system for presenting information from 
at least one provider to a plurality of customers over a 
plurality of electronic channels of distribution, the 
system comprising : 
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5 a formatting means for receiving the 

information from the provider and formatting the 
information for storage; 

a database server means for (i) receiving and 
storing the information from the formatting means, and 
10 (ii) storing customer data identifying at least a 

preferred one of the plurality of electronic channels of 
distribution; and 

an application server means coupled to the 
database server means and the plurality of electronic 
channels of distribution, the application server means 
for (i) receiving the information from the database 
server, (ii) formatting the information for distribution 
over at least one of the electronic channels in response 
to at least some of the customer data, and (iii) 
distributing the information to at least one of the 
plurality of customers over the at least one preferred 
electronic channel of distribution. 
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